Generating a response to a client device in an internet of things domain

ABSTRACT

The present disclosure relates to a method and device to generate a response to a client device in an IoT domain. The disclosed computing device can receive a request from a client device to retrieve information from an Internet of Things (IoT) Application Programming Interface (API), and request a plurality of objects in a domain from the IoT API. Then, the computing device extracts a plurality of names corresponding to the plurality of objects, and pluralizes each of the plurality of names corresponding to the plurality of objects. Next, the computing device generates a link for each pluralized name. Further, the computing device generates a response to the client device by embedding the link for each pluralized name.

BACKGROUND

A generic Internet of Things (IoT) model generally contains thefollowing blocks: ThingType, which describes a class model for definingIoT classes and attributes; ThingformationType, which describes a classmodel for defining IoT messaging classes and attributes;RelationshipType, which describes a class model for defining IoTinter-Thing or inter-Thingformation relationships; Thing, whichdescribes an instance model for IoT object instances; Thingformation,which describes an instance model for IoT messaging instances; andRelationship, which describes an instance model for IoT relationshipinstances. Such generic IoT model does not provide domain-specificrepresentational state transfer (REST) application programming interface(API). Therefore, it is difficult for client developers and clientapplications to work with the generic IoT model.

BRIEF DESCRIPTION OF THE DRAWINGS

The following detailed description references the drawings, wherein:

FIG. 1 is a block diagram of an example environment for an IoT model inwhich a domain-specific REST controller is deployed;

FIG. 2 is a block diagram of an example response generation using thedomain-specific REST controller;

FIGS. 3A-3C show example attributes from generic responses extracted bythe domain-specific REST controller;

FIG. 4 shows an example response generated by the domain-specific RESTcontroller;

FIG. 5 is a block diagram of an example generation of response includingindividual resource representations using the domain-specific RESTcontroller;

FIG. 6A shows example attributes from generic responses corresponding toa Thing as extracted by the domain-specific REST controller;

FIG. 6B shows example attributes from generic responses corresponding toa Thingformation as extracted by the domain-specific REST controller;

FIG. 7A shows an example response including dynamically generatedattributes and link to a Thing as generated by the domain-specific RESTcontroller;

FIG. 7B shows an example response including dynamically generatedattributes and link to a Thingformation as generated by thedomain-specific REST controller;

FIG. 8 is a block diagram of an example generation of response includingresource links for related thingformations using the domain-specificREST controller;

FIGS. 9A-9D show example responses illustrating dynamic generation ofresource links for related thingformations using the domain-specificREST controller;

FIG. 10 is a block diagram of an example generation of responseincluding resource links for related things using the domain-specificREST controller;

FIGS. 11A-11D show example responses illustrating dynamic generation ofresource links for related things using the domain-specific RESTcontroller;

FIG. 12 is a block diagram of an example generation of responseincluding resource links for nested resources using the domain-specificREST controller;

FIGS. 13A-13C show example responses illustrating dynamic generation ofresource links for nested resources using the domain-specific RESTcontroller;

FIG. 14 is a flowchart of an example process to generate a response to aclient device in an IoT domain;

FIG. 15 is a flowchart of an example process to generate a response to aclient device in an IoT domain;

FIG. 16 is a flowchart of an example process to generate a response to aclient device in an IoT domain; and

FIG. 17 is a block diagram of an example network device to generate aresponse to a client device in an IoT domain.

DETAILED DESCRIPTION

Given the generic IoT model, a domain-specific controller according tothe present disclosure will dynamically serve this model in adomain-specific REST API. It will expose a collection of resourceendpoints encoded using the Hypertext Application Language (HAL) formatat the root (‘/’) of the REST API, which are based on the pluralizednames of the ThingType objects defined in the IoT model. The discloseddomain-specific controller also transforms and exposes both Things andThingformation as domain-specific individual and collection resourcerepresentations with attributes and Hypermedia as the Engine ofApplication State (HATEOAS) links. It will generate HATEOAS Links in agiven resource to domain-specific message collection endpoints orrelated resource individual or collection endpoints usingdomain-specific Rels for Thingformation message types in the IoT domain.Changes in the underlying IoT domain are immediately reflected by thedomain-specific controller to interacting client code, withoutrestarting the domain-specific API application or incurring anydowntime.

Overview

FIG. 1 shows a block diagram of an example environment for an IoT model,in which a domain-specific REST controller is deployed. In FIG. 1,Client Application 100 makes a request 120 to a domain-specific RESTcontroller 105. Domain-specific REST controller 105 then interacts witha generic Internet of Things (IoT) API 110 to produce a response for anIoT client. Specifically, domain-specific REST controller 105 sends arequest 130 to IoT API 110 and receives a generic response (e.g.,response 140) from IoT API 110. Then, domain-specific REST controller105 generates a domain-specific response (e.g., response 150) based onthe generic response (e.g., response 140) received from IoT API 110.Note that in some cases, domain-specific REST controller 105 may sendmultiple requests (e.g., multiple requests 130) to IoT API 110 andreceive multiple responses (e.g., responses 140) in order to generate aresponse (e.g., response 150) to a request (e.g., request 120) receivedfrom client application 100.

As used throughout this disclosure, “ThingType” generally describes aclass model for defining IoT classes and attributes;“ThingformationType” generally describes a class model for defining IoTmessaging classes and attributes; “RelationshipType” generally describesa class model for defining IoT inter-Thing or inter-Thingformationrelationships; “Thing” generally describes an instance model for IoTobject instances; “Thingformation” generally describes an instance modelfor IoT messaging instances; and “Relationship” generally describes aninstance model for IoT relationship instances.

Entry Points

FIG. 2 is a block diagram of an example response generation using thedomain-specific REST controller. FIGS. 3A-3C show example attributesfrom generic responses extracted by the domain-specific REST controller.FIG. 4 shows an example response generated by the domain-specific RESTcontroller.

Specifically, in FIG. 2, a client 200 makes a Hypertext TransferProtocol (HTTP) request to the domain-specific REST controller. Inparticular, the request corresponds to a root Uniform Resource Locator(URL) in a domain-specific REST API. The domain-specific REST controllerreceives the request from client 220 and begins processing the request.First, the domain-specific REST controller requests for all ThingTypesin an IoT domain 230 from IoT API 210. IoT API 210 will then send back aresponse, which is shown as response 300 in FIGS. 3A-3C. In thisexample, response 300 includes three different ThingTypes, such as, aRack (as shown in attributes 310), a Device (as shown in attributes320), and a GraphicsCard (as shown in attributes 330).

Next, the domain-specific REST controller extracts names from thereturned ThingTypes 240, and pluralizes the extracted names 250. Forexample, from attributes 310-330, the domain-specific REST controllerwill extract “Rack,” “Device,” and “GraphicsCard” as names of Things inthe IoT domain. Here, because the names are extracted from ThingTypes,the names are in a singular form. Then, the domain-specific RESTcontroller pluralizes these names, because resource names need to bepluralized according to the Hypertext Application Language (HAL)standard. Thus, the Thing names will become “Racks,” “Devices,” and“GraphicsCards.” Thereafter, the domain-specific REST controllergenerates a HAL link for each pluralized name 260. The pluralized namesare used in the rel portion of response 400. The href portion is thegenerated HAL link, which is the pluralized name appended to the rootaddress of the domain-specific REST controller application. In thisexample, the HAL link generated for Rack is http://localhost:8000/Racks;the HAL link generated for Device is http://localhost:8000/Devices; theHAL link generated for GraphicsCard ishttp://localhost:8000/GraphicsCards.

The domain-specific REST controller then joins together the generatedlinks in a response map entry with the key _links as per HAL standardand embeds the response map entry in an HTTP response 400 as shown inFIG. 4 to client 200. Note that, in response 400, instead of genericThing names, the rel and href portions include domain-specificpluralized object names and links.

Generally, a REST application has a limited set of entry points. The setof entry points includes links where a client uses to start the RESTapplication. The client then reaches other resources in the RESTapplication by following a series of links in the response map returnedfrom an entry point. In some implementations, the entry points mayrepresent top level resources (e.g., http://localhost:8000/Racks may bethe root URL for the Rack type resources; http://localhost:8000/Devicesmay be the root URL for the Device type resources;http://localhost:8000/GraphicsCards may be the root URL for theGraphicsCard type resources). In some implementations, the entry pointsmay represent ThingformationTypes (e.g., Statuses, Events, Messages,etc.) instead of ThingTypes (e.g., Racks, Devices, GraphicsCards, etc.).

Individual or Collection Resource Representations

With reference to FIG. 5, the response generation of individual orcollection resource representations begins when a client 500 makes anHTTP request to the domain-specific REST controller. The domain-specificREST controller receives the request from the client device at 510 andproceeds to generate an IoT model at 520 for a response to client 500.Specifically, the domain-specific REST controller creates an appropriateresponse of Things or Thingformations by interacting with IoT API 515.Then, the domain-specific REST controller determines whether theresponse is a collection response at 530. If the response is acollection response, then for each Thing or Thingformation 540, thedomain-specific REST controller will create a response map and add allthe attributes from the Attribute sub-collection of each Thing orThingformation directly to the response map at 550. On the other hand,if the response is not a collection response (e.g., the response is anindividual response), the domain-specific REST controller will create asingle response map and add the attributes of a Thing or Thingformationto the response map at 550.

Next, the domain-specific REST controller determines whether theresponse map being produced is for a Thingformation at 555. If theresponse map is produced for a Thingformation, the domain-specific RESTcontroller will create a new Thing map and add the Thing Attributes fromthe thingAttribute sub-collection of the Thingformation to the Thing map570. Then, the domain-specific REST controller will add thethingAttribute map to the response map with a Key, which is the name ofthe ThingType of the Thing that is associated with the Thingformation575. The domain-specific REST controller generates Hypermedia as theEngine of Application State (HATEOAS) links and adds them to theresponse map using the Key links as per HATEOAS standard 560. If theresponse map is not produced for a Thingformation (e.g., produced for aThing), then the domain-specific REST controller will generateHypermedia as the Engine of Application State (HATEOAS) links and addthem to the response map using the Key _links as per HATEOAS standard560.

Here, the domain-specific REST controller needs to determine whether theresponse is a collection response at 565. The decision made at 530 canbe reused without additional computation. If the response is acollection response, the domain-specific REST controller will wrap theindividual response maps together in an overall response map with thekey _embedded and a sub-key, which is the pluralized name of theThingType or ThingformationType (e.g., “Devices”) of the Things orThingformations being returned as per HATEOAS standard at 580. Theresponse map is then returned to client 500 in an HTTP response at 590.On the other hand, if the response is not a collection response (e.g.,an individual response), then the domain-specific REST controller willdirectly return the response map in an HTTP response to client 500 at590. Therefore, FIG. 5 covers response generation for an individualThing or Thingformation, as well as for a collection of Things orThingformations.

For example, FIG. 6A shows example attributes from generic responsescorresponding to a Thing as extracted by the domain-specific RESTcontroller. FIG. 7A shows an example response including dynamicallygenerated attributes and link to a Thing as generated by thedomain-specific REST controller. Here, a generic IoT representation ofthing includes a plurality of attributes 610 (e.g., ip, hdd (hard diskdrive), etc.) and a link 620 to the Thing object (e.g.,http://localhost:8080/things/2(?projection)”). The attributes of Thing(e.g., ip, hdd, etc.) and their corresponding values are extracted fromthe Attribute sub-section of the generic response and added directly tothe root level of the domain-specific response map (e.g., Thing 700 inFIG. 7A).

As another example, FIG. 6B shows example attributes from genericresponses corresponding to a Thingformation as extracted by thedomain-specific REST controller. FIG. 7B shows an example responseincluding dynamically generated attributes and link to a Thingformationas generated by the domain-specific REST controller. Here, a generic IoTrepresentation of Thingformation includes a plurality of attributes forthe Thingformation (e.g., text 660) and a link 670 to the Thingformationobject (e.g., http://localhost:8080/thingformations/2(?projection)”).The attributes of Thingformation (e.g., text 660) and theircorresponding values are extracted from the Attribute sub-section of thegeneric response and added directly to the root level of thedomain-specific response map (e.g., Thingformation 750 in FIG. 7B).

Moreover, as shown in FIG. 6B, Thingformation 650 is related to a Thing,which corresponds to a ThingType. The domain-specific REST controllercan also determine the ThingType corresponding to the Thing that isrelated to the Thingformation. Then, the domain-specific REST controllerextracts the name of the ThingType (e.g., “Device”) and use the name asa Key in the response map. The attributes of the Thing that is relatedto Thingformation (e.g., hdd 670) and their corresponding values areextracted from the thingAttributes sub-section of the generic responseand, as a part of dynamically generated attributes and link toThingformation 780, added to the domain-specific response map 750 underthe Key (e.g., “Device”).

Note that the generated domain-specific response map can be directlydeserialized into an object in an object oriented programming language.Also, the attributes used in this example are for illustration purposesonly. They can be any piece of information that determines theproperties or characteristics of an object in the IoT domain. Theattributes are dynamically extracted from the generic response and addedinto the domain-specific response map. This process is performedautomatically and does not depend on knowledge of particular attributesrelated to an IoT object (e.g., a Thing, a Thingformation, etc.)

Resource Links of Related Thingformations

FIG. 8 is a block diagram of an example generation of response includingresource links for related Thingformations using the domain-specificREST controller. FIG. 8 includes a client 800 and an IoT API 810. Theresponse generation of resource links begins when client 800 makes anHTTP request to a domain-specific REST controller. The domain-specificREST controller receives request from client device at 820. At 830, thedomain-specific REST controller generates an appropriate response modelfor the resource (e.g., a Thing) using IoT API 810. Next, at 840, thedomain-specific REST controller requests a collection ofThingformationTypes from IoT API using the ThingType of the Thing beingreturned. At 850, for each returned ThingformationType, thedomain-specific REST controller generates a link object (e.g., a newHATEOAS link), whereas the rel portion of the link is the pluralizedname of the ThingformationType and the href portion of the link is thepluralized name of the ThingformationType appended to the URL of theindividual Thing being returned. Thereafter, the domain-specific RESTcontroller adds the links to the response model at 860, and returns inan HTTP response map to the client device at 870.

FIGS. 9A-9D show example responses illustrating dynamic generation ofresource links for related thingformations using the domain-specificREST controller. Specifically, the domain-specific REST controller firstde-pluralizes the ThingType (e.g., “Devices” to “Device”) extracted fromthe URL corresponding to a Thing. Then, in the IoT API, thedomain-specific REST controller can perform a search by name in theThingTypes, where the name equals to the de-pluralized ThingType (e.g.,“Device”). The domain-specific REST controller will then receive aresponse corresponding to a ThingType of Thing 900 as shown in FIG. 9A.

Next, the domain-specific REST controller can extract a link toThingformationType 920 from ThingType of Thing 900. Following theextracted link, the domain-specific REST controller will receive aresponse corresponding to ThingformationType 940 as shown in FIGS.9B-9C. In this example, ThingformationType 940 includes two differentThingformationTypes: the first ThingformationType is called “Status,”and the second ThingformationType is called “SystemReboot.” For eachThingformationType 940, the domain-specific REST controller generates alink object, where the rel portion of the link is the pluralized name ofthe ThingformationType (e.g., “Statuses” or “systemReboots”) asextracted from portion 950 and 960 of the generic response map. Also,the href portion of the link is the pluralized name of theThingformationType appended to the URL of the resource representation.In this example, the URL of the resource representation is an individualdevice, e.g., http://localhost:8000/Devices/2. Thus, the dynamicallygenerated links to ThingformationTypes 980 in a resource representation(e.g., Thing 970) become http://localhost:8000/Devices/2/Statuses forStatuses and http://localhost:8000/Devices/2/SystemReboots forSystemReboots. The generated links allow an IoT user to retrieve allstatuses or system reboot information related to a particular IoTdevice, i.e., same information provided by the generic IoT API whenfollowing the links 955 and 965 in the generic responses.

The Thingformations here are considered as related, because they arerelated to a particular Thing object. Note that there may be additionalThingformations besides the ones illustrated here (e.g., statuses,SystemReboots). However, the additional Thingformations are not relatedto the same Thing object (e.g., “Device”). Therefore, the additionalThingformations shall be appear in the links in a response mapcorresponding to a Device object.

Resource Links of Related Things

In an IoT API, individual Things can be related to each other. Forexample, a rack can include a plurality of devices; and, a device caninclude a plurality of graphics cards. In this manner, a rack, a device,and graphics cards can be related to each other. This section describesthe generation of resource links for such related resources.

FIG. 10 is a block diagram of an example generation of responseincluding resource links for related things using the domain-specificREST controller. FIG. 10 includes a client 1000 and an IoT API 1010. Theresponse generation of resource links begins when client 1000 makes anHTTP request to a domain-specific REST controller. The domain-specificREST controller receives request for Thingformation from client deviceat 1020. At 1030, the domain-specific REST controller generates anappropriate response model for the resource (e.g., a Thingformation)using IoT API 1010. Next, at 1040, the domain-specific REST controllerrequests a collection of ThingTypes from the IoT API using the relatedThings of the Thingformation being returned. At 1050, for each returnedThingType, the domain-specific REST controller generates a link object(e.g., a new HATEOAS link), whereas the rel portion of the link is thesingular form name of the ThingType and the href portion of the link isthe pluralized name of the ThingType appended to the URL of the root,and then append the identifier of the individual Thing object.Thereafter, the domain-specific REST controller adds the links to theresponse model at 1060, and returns in an HTTP response map to theclient device at 1070.

FIGS. 11A-11D show example responses illustrating dynamic generation ofresource links for related things using the domain-specific RESTcontroller. Specifically, as shown in FIG. 11A, from a representation ofThingformation 1100, the domain-specific REST controller first extractsa related Thing 1120. Then, the domain-specific REST controller willreceive a generic response corresponding to a related Thing ofThingformation 1140 as shown in FIG. 11B. The domain-specific RESTcontroller extracts a ThingType 1160 of the related Thing 1140. Ageneric response corresponding to the ThingType is shown in FIG. 11C.Here, ThingType 1180 includes an identifier, a name, and a descriptionof the Thing. These information (e.g., “Device”) are used to dynamicallygenerate a link in Thingformation response 1185. FIG. 11D shows adomain-specific response of Thingformation 1190, which includes adynamically generated link to a related Thing (e.g., “Device”)http://localhost:8000/Devices/2.

It shall be noted that this link is generated based on the attributes inthe ThingType of a related Thing to the Thingformation. Also, becauseonly one Thing can be associated with a Thingformation, the rel portionof the link will have a singular form of the ThingType name (“Device”),but the href portion of the link will use the plural form of theThingType name (“Devices”). Further, the href portion appends thepluralized name of the ThingType (“Devices”) to the root URL(http://localhost:8000), and then append the identifier of theindividual Thing object (“2”). Also, every resource includes a self linkthat is identical to the current URL per HAL standard.

Resource Links of Nested Resources

A top-level resource generally refers to an individual or collection ofresource that can be accessed by appending the resource information(e.g., type and identifier) to the root URL. For example,http://localhost:8000/devices/2 points to a top-level resource that isan individual device. The top-level resource is a global object and itsexistence does not depend on the existence of any other objects. On theother hand, a nested resource generally refers to a second levelresource that is related to a top-level resource. For example,http://localhost:8000/devices/2/GraphicsCards points to a collection ofgraphics cards that are nested under a particular device. Although theremight be many graphics cards existing in the IoT domain, the above linkwill only show graphics cards that are related to a particular device(e.g., belonging to the device with identifier number 2). In otherwords, nested resources can be considered as resources that are filteredbased on their relationship with an individual or collection oftop-level resources.

In fact, the dynamically generated links to ThingformationTypes 980 inFIG. 9D are another example of nested resources. As mentioned whendescribing FIG. 8, in order to generate the nested Thingformation links,the domain-specific REST controller retrieves the ThingType of theThing, and then requests all ThingformationTypes using the ThingType.Thus, the link generation of nested resource corresponding to nestedThingformations is relatively simple.

The link generation of nested resources corresponding to Things is morecomplex than that corresponding to Thingformations, because therelationship between things are explicit. Thus, a relationship objectneeds to be created within the IoT domain to describe relationshipsbetween things in the IoT domain.

Referring now to FIG. 12, the response generation of nested resourcescorresponding to things begins when a client 1200 makes an HTTP requestto the domain-specific REST controller. At 1210, the domain-specificREST controller receives the request from the client device 1200. Then,at 1220, the domain-specific REST controller generates an appropriateIoT response model for the resource (e.g., a Thing) using the IoT API1215. Next, the domain-specific REST controller requests a collection ofRelationshipTypes from the IoT API using the ThingType of the Thingbeing returned as a source qualifier at 1230. At 1240, for each returnedRelationshipType, the domain-specific REST controller makes a request tothe IoT API for the ThingType, which is the Target Qualifier of theRelationshipType. At 1250, the domain-specific REST controllerdetermines whether the cardinality of each returned RelationshipTypeequals MANY. If the RelationshipType cardinality is MANY, then thedomain-specific REST controller pluralizes target ThingType name asrelName at 1260. On the other hand, if the RelationshipType cardinalityis not MANY (e.g., the RelationshipType cardinality is ONE), then thedomain-specific REST controller creates a variable relName and settarget ThingType name as relName at 1270. At 1280, for each target type,the domain-specific REST controller will create a link object, where therel portion of the link is the relName and the href portion of the linkis the relName appended to the URL of the individual resourcerepresentation being created. At 1290, the domain-specific RESTcontroller will add the Links to the response model. Specifically, thedomain-specific REST controller will add ThingAttributes map to theresponse map with ThingType name of associated ThingType as a key, andreturn it in an HTTP response to client 1200.

FIGS. 13A-13C show example responses illustrating dynamic generation ofresource links for nested resources using the domain-specific RESTcontroller. In this example, one rack can contain many devices. Assumingthat this is the only relationship that a rack can have to other thingsin the IoT domain. Also, for illustration purposes only, assuming thatthe identifier corresponding to the ThingType for the Racks is 1 and theidentifier corresponding to the ThingType for the Devices is 2.Moreover, to describe the relationship between Rack and Devices in thisexample, a RelationshipType is created, which is shown in FIG. 13A.Specifically, RelationshipType shown in FIG. 13A maps the ThingType withidentifier 1 (e.g., Racks) to the ThingType with identifier 2 (e.g.,Devices). In particular, representation of RelationshipType is obtainedby using ThingType of Thing as source qualifier ID 1300 (e.g.,identifier “1” corresponding to Racks as the source qualifier ID) and itincludes the following lines:

“cardinality”: “MANY”, “sourceType”: “THING”, “targetType”: “THING”,“sourceQualifierType”: “THING_TYPE”, “targetQualifierType”:“THING_TYPE”, “sourceQualifierId”: 1, “targetQualifierId”: 2,The above RelationshipType attributes define that the relationship typeis from Racks to Devices. Moreover, the cardinality value is “MANY,”which indicates that the target of the RelationshipType will be MANY.Thus, the relationship can be a 1-to-MANY Relationship, or aMANY-to-MANY relationship, or even a 0-to-MANY relationship.

Then, the domain-specific REST controller will request the ThingTypeusing the RelationshipType target qualifier 1310. Following targetqualifier 1310, the domain-specific REST controller will receive ageneric response corresponding to a Target ThingType 1330 as shown inFIG. 13B. The generic response corresponding Target ThingType 1330includes the following lines:

“identifier”: 2, “name:: “Device”, “description”: “Device”,Based on the above target ThingType attributes information 1340, thedomain-specific REST controller can determine that the target ThingTypeis pointing to a Device in this example. If the RelationshipType isMANY, the domain-specific REST controller will pluralize the targetThingType name. Otherwise, the domain-specific REST controller will usethe singular form of the target ThingType name.

Then, the domain-specific REST controller can dynamically generatenested links to related things 1360 as shown in FIG. 13C. Specifically,the domain-specific REST controller uses either singular or plural formof target ThingType name as the rel portion of the link depending on theRelationshipType. Also, the domain-specific REST controller appendseither singular or plural form of the target ThingType name (e.g.,“Devices”) to the URL corresponding to the link of the individual thing(e.g., a Rack with identifier 1). Thus, in this example, thedomain-specific REST controller will generate a nested link 1360 whosehref portion is in the form of http://localhost:8000/Racks/1/Devices.

Note that although a relationship between ThingType and ThingType isillustrated in this example, a RelationshipType could also be created todescribe any relationships between any types of objects in an IoTdomain, for example, a relationship between a user and a thing (e.g.,users and things that each user owns), a relationship between a user andan entity (e.g., users and entities that each user belongs to), etc.

Processes to Generate a Response to a Client Device in an IoT Domain

In discussing FIGS. 14-16, references may be made to the components inFIGS. 1-13 to provide contextual examples. In one implementation, thedomain-specific REST controller 105 as in FIG. 1 executes operations1410-1460 to generate a response to a client device in an IoT domain. Inone implementation, the domain-specific REST controller 105 as in FIG. 1executes operations 1510-1550 to generate a response to a client devicein an IoT domain. In one implementation, the domain-specific RESTcontroller 105 as in FIG. 1 executes operations 1610-1660 to generate aresponse to a client device in an IoT domain. Further, although FIGS.14-16 are described as implemented by a controller, it may be executedon other suitable components. For example, FIGS. 14-16 may beimplemented in the form of executable instructions on a machine-readablestorage medium 1720 as in FIG. 17.

FIG. 14 is a flowchart of an example process to generate a response to aclient device of an IoT domain using domain-specific REST controller.First, a computing device (e.g., the domain-specific REST controller)receives a request from a client device to retrieve information from anInternet of Things (IoT) Application Programming Interface (API)(operation 1410). Here, the IoT API is a generic IoT API.

Then, the computing device requests a plurality of objects in a domainfrom the IoT API (operation 1420). Moreover, the computing deviceextracts a plurality of names corresponding to the plurality of objects(operation 1430). Then, the computing device pluralizes each of theplurality of names corresponding to the plurality of objects (operation1440).

Further, the computing device generates a link for each pluralized name(operation 1450). The link for each pluralized name comprises a linkusing Hypertext Application Language (HAL) format. Specifically, a relportion of the link includes the pluralized name; and a href portion ofthe link includes a backslash concatenated with the pluralized name. Insome implementations, the computing device may join the link for eachpluralized name in a _links map in the response to the client device.

Subsequently, the computing device generates a response to the clientdevice by embedding the link for each pluralized name (operation 1460).The response to the client device may include entry points to adomain-specific API.

FIG. 15 is a flowchart of an example process to generate a response to aclient device of an IoT domain using domain-specific REST controller.First, a computing device (e.g., the domain-specific REST controller)receives a request from a client device to retrieve informationcorresponding to a particular object from an Internet of Things (IoT)Application Programming Interface (API) (operation 1510). Then, thecomputing device creates a response map based on the request (operation1520). Moreover, the computing device retrieves a plurality ofattributes associated with the particular object from the IoT API(operation 1530). Then, the computing device generates at least one linkcorresponding to the particular object; (operation 1540). Subsequently,the computing device generates a response to the client device by addingthe plurality of attributes and the at least one link to the responsemap (operation 1550).

In some implementations, the computing device further determines whetherthe response includes a collection of objects. If the response includesthe collection of objects, for each object in the collection, thecomputing device will create a response map corresponding to arespective object. Then, the computing device will retrieve a pluralityof attributes from the IoT API associated with the respective object.Further, the computing device generates at least one link correspondingto the respective object. Then, the computing device adds the pluralityof attributes and the at least one link corresponding to the respectiveobject to the response map. In some implementations, if the responseincludes the collection of objects, the computing device furtherpluralizes a type name corresponding to the particular object, andembeds each response map corresponding to the respective object to theresponse to the client device using the pluralized type name as a key.

In some implementations, the computing device determines whether theparticular object is a thing or a message. If the particular object is amessage, the computing device will retrieve thing attributes associatedwith the message from the IoT API, and add the thing attributes to theresponse map. Specifically, to add the thing attributes to the responsemap, the computing device determines an object type associated with themessage, and adds the thing attributes to the response map using a typename of the object type associated with the message as a key.

FIG. 16 is a flowchart of an example process to generate a response to aclient device of an IoT domain using domain-specific REST controller.First, a computing device (e.g., the domain-specific REST controller)receives a request from a client device to retrieve informationcorresponding to a particular relationship from an Internet of Things(IoT) Application Programming Interface (API) (operation 1610). Thecomputing device then creates a response map based on the request(operation 1620). Next, the computing device retrieves a plurality ofrelationship types associated with the particular relationship from theIoT API (operation 1630). Also, the computing device retrieves an objecttype using a respective retrieved relationship type as a targetqualifier from the IoT API (operation 1640). Further, the computingdevice generates a link object for each object type (operation 1650).Subsequently, the computing device generates a response to the clientdevice by adding a plurality of object attributes to the response map,whereas a type name of the each object type is used as a key.

In some implementations, the computing device retrieves the plurality ofrelationship types associated with the particular relationship from theIoT API by using an object type of an object associated with arespective relationship type as a source qualifier from IoT API.

In some implementations, the computing device further determines whethera cardinality of a respective relationship type is many. If so, thecomputing device pluralizes the type name of the object type, and usesthe pluralized type name as a rel portion in the response to the clientdevice. If, on the other hand, the cardinality of the respectiverelationship type is one, the computing device will use a singular typename as the rel portion in the response to the client device.

In some implementations, the computing device retrieves a plurality ofmessage types using an object type of a particular object from the IoTAPI. For each of the plurality of message types, the computing devicegenerates a link object. Specifically, a rel portion of the generatedlink includes a pluralized name of a respective message type, and a hrefportion of the generated link includes a pluralized name of therespective message type appended to the link. Then, the computing deviceadds the link object to the response to the client device.

In some implementations, the computing device retrieves a plurality ofobject types using a related object of a particular message from the IoTAPI. For each of the plurality of object types, generating a linkobject. Specifically, a rel portion of the generated link includes asingular name of a respective object type, and a href portion of thegenerated link includes a pluralized name of the respective object typeappended to the link. Then, the computing devices adds the link objectto the response to the client device.

Network Device to Generate a Response to a Client Device in an IoTDomain

FIG. 17 is a block diagram of an example network device with at leastone processor 1710 to execute instructions 1730-1780 within amachine-readable storage medium 1720 to generate a response to a clientdevice in an IoT domain. Although the network device 1700 includes atleast one processor 1710 and machine-readable storage medium 1720, itmay also include other components that would be suitable to one skilledin the art. For example, network device 1700 may include an additionalprocessing component and/or storage. In another implementation, thenetworking component (e.g., domain-specific REST controller 105 inFIG. 1) executes instructions 1730-1780. Network device 1700 is anelectronic device with the at least one processor 1710 capable ofexecuting instructions 1730-1780, and as such implementations of networkdevice 1700 include a mobile device, server, data center, networkingdevice, client device, computer, or other type of electronic devicecapable of executing instructions 1730-1780. The instructions 1730-1780may be implemented as methods, functions, operations, and otherprocesses implemented as machine-readable instructions stored on thestorage medium 1720, which may be non-transitory, such as hardwarestorage devices (e.g., random access memory (RAM), read only memory(ROM), erasable programmable ROM, electrically erasable ROM, harddrives, and flash memory).

The at least one processor 1710 may fetch, decode, and executeinstructions 1730-1780 to generate a response to a client device in anIoT domain. Specifically, the at least one processor 1710 executesinstructions 1730-1780 to: receive a request from a client device toretrieve information from an Internet of Things (IoT) ApplicationProgramming Interface (API); request a plurality of objects in a domainfrom the IoT API; extract a plurality of names corresponding to theplurality of objects; pluralize each of the plurality of namescorresponding to the plurality of objects; creatie a response map basedon the request; determine whether the response includes a collection ofobjects; determine whether the particular object is a thing or amessage; determine whether an object type is associated with themessage; determine whether a cardinality of a respective relationshiptype is many; retrieve a plurality of attributes associated with aparticular object from the IoT API; retrieve a plurality of relationshiptypes associated with a particular relationship from the IoT API;retrieve an object type using a respective retrieved relationship typeas a target qualifier from the IoT API; retrieve a plurality ofrelationship types using an object type of an object associated with arespective relationship type as a source qualifier from IoT API;retrieve a plurality of message types using an object type of aparticular object from the IoT API; retrieve a plurality of object typesusing a related object of a particular message from the IoT API;generate at least one link corresponding to a particular object; jointhe links in a _links map; add the plurality of attributes and the atleast one link corresponding to a respective object to the response map;add the thing attributes to the response map using a type name of theobject type associated with the message as a key; use the pluralizedtype name as a rel portion in the response to the client device if thecardinality of a respective relationship type is many; use a singulartype name as the rel portion in the response to the client device if thecardinality of a respective relationship type is one; embed eachresponse map corresponding to the respective object to the response tothe client device using the pluralized type name as a key; generate aresponse to the client device by adding the plurality of attributes andthe at least one link to the response map or by embedding the link foreach pluralized name; etc.

The machine-readable storage medium 1720 includes instructions 1730-1780for the processor 1710 to fetch, decode, and execute. In anotherexample, the machine-readable storage medium 1720 may be an electronic,magnetic, optical, memory, storage, flash-drive, or other physicaldevice that contains or stores executable instructions. Thus, themachine-readable storage medium 1720 may include, for example, RandomAccess Memory (RAM), an Electrically Erasable Programmable Read-OnlyMemory (EEPROM), a storage drive, a memory cache, network storage, aCompact Disc Read Only Memory (CDROM) and the like. As such, themachine-readable storage medium 1720 may include an application and/orfirmware which can be utilized independently and/or in conjunction withthe at least one processor 1710 to fetch, decode, and/or executeinstructions of the machine-readable storage medium 1720. Theapplication and/or firmware may be stored on the machine-readablestorage medium 1720 and/or stored on another location of the networkdevice 1700.

We claim:
 1. A method comprising: receiving, by a computing device, a request from a client device to retrieve information from an Internet of Things (IoT) Application Programming Interface (API); requesting, by the computing device, a plurality of objects in a domain from the IoT API; extracting, by the computing device, a plurality of names corresponding to the plurality of objects; pluralizing, by the computing device, each of the plurality of names corresponding to the plurality of objects; generating, by the computing device, a link for each pluralized name; and generating, by the computing device, a response to the client device by embedding the link for each pluralized name.
 2. The method of claim 1, wherein the link for each pluralized name comprises a link using Hypertext Application Language (HAL) format.
 3. The method of claim 2, wherein a rel portion of the link comprises the pluralized name, and wherein a href portion of the link comprises a backslash concatenated with the pluralized name.
 4. The method of claim 1, wherein the IoT API is a generic IoT API, and wherein the response to the client device comprises entry points to a domain-specific API.
 5. The method of claim 1, further comprising: joining, by the computing device, the link for each pluralized name in a _links map in the response to the client device.
 6. A method comprising: receiving, by a computing device, a request from a client device to retrieve information corresponding to a particular object from an Internet of Things (IoT) Application Programming Interface (API); creating, by the computing device, a response map based on the request; retrieving, by the computing device, a plurality of attributes associated with the particular object from the IoT API; generating, by the computing device, at least one link corresponding to the particular object; and generating, by the computing device, a response to the client device by adding the plurality of attributes and the at least one link to the response map.
 7. The method of claim 6, further comprising: determining whether the response includes a collection of objects; in response to the response including the collection of objects, for each object in the collection: creating, by the computing device, a response map corresponding to a respective object; retrieving, by the computing device, a plurality of attributes associated with the respective object from the IoT API; generating, by the computing device, at least one link corresponding to the respective object; and adding, by the computing device, the plurality of attributes and the at least one link corresponding to the respective object to the response map.
 8. The method of claim 7, further comprising: in response to the response including the collection of objects, pluralizing, by the computing device, a type name corresponding to the particular object; and embedding, by the computing device, each response map corresponding to the respective object to the response to the client device using the pluralized type name as a key.
 9. The method of claim 6, further comprising: determining whether the particular object is a thing or a message; in response to the particular object being the message: retrieving thing attributes associated with the message from the IoT API; and adding the thing attributes to the response map.
 10. The method of claim 9, wherein adding the thing attributes to the response map further comprising: determining an object type associated with the message, adding the thing attributes to the response map using a type name of the object type associated with the message as a key.
 11. A method comprising: receiving, by a computing device, a request from a client device to retrieve information corresponding to a particular relationship from an Internet of Things (IoT) Application Programming Interface (API); creating, by the computing device, a response map based on the request; retrieving, by the computing device, a plurality of relationship types associated with the particular relationship from the IoT API; retrieving, by the computing device, an object type using a respective retrieved relationship type as a target qualifier from the IoT API; generating, by the computing device, a link object for each object type; and generating, by the computing device, a response to the client device by adding a plurality of object attributes to the response map, wherein a type name of the each object type is used as a key.
 12. The method of claim 11, wherein retrieving the plurality of relationship types associated with the particular relationship from the IoT API further comprises: retrieving the plurality of relationship types using an object type of an object associated with a respective relationship type as a source qualifier from IoT API.
 13. The method of claim 11, further comprising: determining whether a cardinality of a respective relationship type is many; in response to the cardinality of the respective relationship type being many, pluralizing the type name of the object type; and using the pluralized type name as a rel portion in the response to the client device; and in response to the cardinality of the respective relationship type being one, using a singular type name as the rel portion in the response to the client device.
 14. The method of claim 11, further comprising: retrieving, by the computing device, a plurality of message types using an object type of a particular object from the IoT API; for each of the plurality of message types, generating a link object, wherein a rel portion comprises a pluralized name of a respective message type, and wherein a href portion comprises a pluralized name of the respective message type appended to the link; and adding the link object to the response to the client device.
 15. The method of claim 11, further comprising: retrieving, by the computing device, a plurality of object types using a related object of a particular message from the IoT API; for each of the plurality of object types, generating a link object, wherein a rel portion comprises a singular name of a respective object type, and wherein a href portion comprises a pluralized name of the respective object type appended to the link; and adding the link object to the response to the client device. 